00100	There are many simple extensions to the SPOT program. One main one is to
00200	add a graph-matcher:  after the scen is read in, when it is compared to a
00300	stored scene, the objects are not only renamed as necessary, they are
00400	permuted as necessary until a match is found or all permutations have been
00500	exhausted.  A second one involves backup. Currently, SPOT simply undoes
00600	any transfer found later to be incorrect; it does not then do any of the
00700	(then-existing) alternative transfers, it simply stays where it is.  Thus
00800	it often errs, makes a false fixup (which works on this one particular case
00900	only,) errs again, undoes the false fixup, and thus is back where it started
01000	(with respect to this particular feature).  A better system should tag each
01100	new transfer into the MUST or MUSNT list by appending the list of its alter-
01200	natives.  After finding a MUST entry which is actually only a MAY, SPOT can
01300	stick it back into MAY and find some one of its alternatives which is still
01400	in the ALWAYS-WAS category (or, if it doesnt't exist, the MAY list) and
01500	transfer it to the MUST list.  Similarly, and incorrect MUSNT entry can
01600	be transferred to MAY, and one of its alternatives raised to MUSNT status,
01700	so long as that alternative doesn't appear on any other list.
01800	
01900	With these two changes, SPOT would be as good as Winston's system. Winston
02000	in fact gives the graph-matcher details, and mentions that it is too good
02100	an algorithm to have any interest to AI researchers except as a unit. There
02200	are many subtle variations on the CF theme, and they have been mentioned
02300	in the BEINGS handout and in the second PUP5 talk writeup (under CONCEPT
02400	FORMATION knowledge). These decisions involve constraints on the task,
02500	which affect what algorithm the CF program can employ.
02600	
02700	A great deal of work remains to be done on the dialog.  There are serious
02800	problems which have not been important ever before: it is reasonable to
02900	demand that the user be "on top of" a dialog which takes five minutes and
03000	runs one page; it is foolhardy if the dialog takes twelve hours and is
03100	hundreds of pages long. Recovering from user error is nontrivial, since
03200	the system should only consult the user when it has run aground.  There is
03300	a problem of how to refer to something that was mentioned once several hours
03400	ago: PUP5 currently demands it by name, which means naming everything and
03500	remenbering all the names of the things you need. This is wasteful (half
03600	the dialog is naming, and only a few of the names are ever mentioned again)
03700	and should be replaced by a facility for referncing objects by describing
03800	what they are, what they do, roughly when and where they were created, etc.
03900	Although this seems plausible (but tedious) with a being-oriented system,
04000	it does not seem at all feasible with a purely rule-based one. Perhaps the
04100	whole idea of gradually building the right program is a poor approach. We
04200	might want the system to slap together some rough approximation to what the
04300	user wants, then let him use it for a while, then process his comments and
04400	modify the program. This iterative process should converge to the right
04500	program quickly, and it is probably desirable because the typical
04600	user doesn't really know what he wants until he sees why he doesn't want
04700	what he initially told you he wanted. Also, even if he is satisfied, he
04800	may later want to modify the program in some way after using it for a
04900	while.  Notice that I am not advocating a system which reads in just
05000	any program and some comments and fixes up the program: it must be a
05100	program (with all the states of the relevant data structures saved as
05200	cmments, perhaps) which the system itself has written. 
05300	
05400	The match to existing scenes should be by picking the closest one, not 
05500	(as cureently) by picking the first one which passes the criteria.
05600	Full Boolean concepts, involving OR and NOT, should be handled.
05700	
05800	One totally new area would be to include semantic world knowledge and to
05900	tell the program what the structure was used for. Then the system could
06000	reject implausible generalizations, hypothesize that certain MAY obser-
06100	vations are really MUST ones, predict some MUSNT relations, and so on.